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REMARKS 

L The Amendments, the Support Therefo^ and Basis for Entry 

No claims have been canceled or added, and claims 1 , 7, and 23 have been amended to leave 
claims 1,4-7, 10-12, 14-16, 18-20, and 23 in the application. No new matter has been added by the 
amendments, wherein claims 1, 7, and 23 have been amended (1) to address the §101 and §112 
issues noted in Sections 3, 4 and 5 of this Response (below), and (2) to specify in claims 7 and 23 
that the generated standardized email address includ es the family name (a feature noted, for example , 
at page 3 lines 4-10 of the application). 

2. Section 6 of the Office Action: Objection to Title 



The title is amended as per the Examiner's 



suggestion. 



h. Section 8 of the Office Action: Rejection of Claims 1, 4-6 under 35 USC §101 

Claim 1 is amended to affirmatively recite the collecting, creating, etc. steps, and also to 
clarify that the instructions are encoded in the program of the storage device. The § 1 01 rejections 
are therefore believed to be traversed. Please note that the text of the rejections is not complete in 
the Office Action, and thus if the rejections are mlaintained, kindly provide a clear and complete 
restatement of the rejections, 

4- Sections 9-11 of the Office Action: Rejection of Claims 1, 4-6 under 35 USC §11 2m 



Claim 1 has been corrected to recite fit instructions : 
address," and this correction is believed to obviate 



5. Section 12 of the Office Action: Rejection of Claims 1. 4-7. 10-12» 14-16. 18-20. and 23 



" rather than "standardized electronic mail 
the §11 2(1) rejections. 



under 35 USC S112m 

All § 1 1 2(2) issues noted in the Office Action are addressed by the amendments to the cl aims. 
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6- Sections 3-5 and 13-17 of the Office Action: Rejection of Independent Claims 1, 7. and 

23 under 35 DSC § 1Q3(*) in view of U.S. Patent 5,987.508 to Aeraharam e.i id. 
<La. The Differences Between the Claimed Invention and the Prior Art 

Before reviewing these rej ections in greater detail, it is initially useful to review the teachings 
of Agraharam el at. Agraharam is directed to the problem that email senders often cannot 
remember a person's email address (see column 1 lines 10-36, column 2 line 66-column 3 line 9). 
Agraharam seeks to bypass this problem by allowing the use of one's telephone number as an email 
address: by creating an "alias email address" which "consists of the recipient's telephone number 
as the recipient name at a well-known and publicized common domain name server" (column 1 lines 
44-47). Thus, a recipient may register with the provider of the invention and provide his/her 
telephone number and "primary" email address (column 3 lines 35-41). The invention then creates 
an alias email address, e.g., [telephone numberj@email. [domain], that senders may use if they do 
not know the recipient's primary email address (column 3 lines 41-50). An example given by the 
patent is that Steve G., whose telephone number is 201-555-8765 and whose primary email address 
is steveg@attmail.com, might be assigned the alias email 2015558765@emaii.att.net after 
registering and providing his telephone number and whose primary email address. 

Column 5 lines 8-23 note that when an alias email such as 2015558765@email.atLnet is 
generated, associated alias emails which include country codes may also be generated, such as 
2015558765@email.att.us.net, 2015558765@email.att.uk.net, 20 15558765@email.att.ca.net, and 
so forth. This allows a sender to use an alias email which either does or does not include a country 
code. 

Further, column 5 lines 24-37 note that since multiple people may share the same telephone 
number, multiple recipients may register with the same telephone number (and with different 
primary email addresses). In this case, so that emails sent to an alias email address are sent to the 
correct recipient at his/her correct primary email address, a name may be added to the alias email 
addresses (such as 20 1 5558765 .steve@emaiLatt.net) so that the alias email is directed to the desired 
individual at his/her correct primary email address. 
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When an email is then sent to an alias email address (e.g., 2015558765@emaii.att.net), the 
provider receives it 3 looks up the primary email address associated vsrith the alias email address (e.g_ 3 
steveg@attmail.com), and forwards the email on to the recipient's primary email address (column 
3 lines 51-66), Where a recipient has not yet registered for the service and a sender sends an email 
to the alias email address (e.g., 2015558765@email.att.net), the system will not be able to locate the 
recipient's primary email address, and here the provider might generate an automated voice mail and 
deliver it to the corresponding telephone number (here 201-555-8765) suggesting that the recipient 
register for the service (column 4 lines 13-41 ; see also column 5 line 38 onward). If the recipient 
does not register, the email can be returned to the sender (column 4 lines 28-41). 

Also, registered users are allowed to search lor the primary email addresses of other 
registered user$: a registered user may enter the telephone number of an intended recipient, and 
thereby receive the actual/primary email address of the recipient rafter than the alias email (column 
6 lines 6-22). 

As noted in the prior Response, independent claim 1 is directed to generation of standardized 
email addresses, and of a searchable database of such addresses. As recited in clause a., name and 
location data for an individual are sought and collected from an information source. As an example, 
a "spider" Or "robot" may comb websites for name and location data related to individuals. As noted 
in clause b. of claim 1, if name and location data are found, an entry is created in a database for the 
individual. This entry may be an "at least partial" entry, i _e. 7 it may contain only rudimentary details 
on name and location. However, as recited in clause c, once sufficient name and location data are 
found - once the name data includes a family name (surname), and once the location data includes 
one or more of a country specific postal address locator code (e.g., a zip code) and/or a region 
specific portion of a telephone number (e.g., an area code) - a standardized electronic mail address 
is created. The standardized electronic mail address includes a personal name code indicative of the 
collected name data of the individual, and a location code indicative of the collected known location 
data of the individual The standardized electronic mail address is then added to the database, and 



-12- 



PAGE 14/25 ' RCVD AT 10/31/2007 2:20:23 PM [Eastern Daylight Time] ■ SVR:USPT0-EFXRM/1 * DNIS:2738300 * CSID:6088312106 * DURATION (mm-ss):0M4 



10/31/07 13:22 FAX 6088312106 



DEW ITT ROSS STEVENS 



E1015 



can be searched by the personal name code and location code to return the standardized electronic 
mail address (clauses d and e). Independent claims 7 and 23 recite similar matter. 

Note that in claim 1 , a database is first built which includes at least partial name and location 
data for an individual, and the invention then creates an email address (and adds it to the database) 
only when the name and location data for the individual is "complete" (i.e., when it includes certain 
items of name and location data), rather than partial. In other words, the invention builds a 
collection of standardized electronic mail addresses over time. As information sources are searched 
for individuals' name and location data, an entry may be created for an individual once name and 
location data are found, but the entry is not completed - i,e„ a standardized electronic mail address 
is not created and added to the individual's entry - unless and until certain name and location data 
is finally found (a family name and one or more of postal address locator code and/or a region 
specific portion of a telephone number). 

The claimed invention therefore differs from Agraharam, wherein a database of standardized 
electronic mail addresses is created, but each entry and standardized electronic mail address in the 
Agraharam database is created immediately once a user registers for the system (which requires that 
the user provide their telephone number and primary email address; see column 3 lines 35-41 and 
column 5 lines 49-52). Agraharam therefore requires registration - that each user "opt in" and 
provide a telephone number and primary email address - and there is no automatic generation of a 
database containing at least partial database entries, and subsequent generation of a standardized 
electronic mail address once certain data (family name, and postal code and/or region-specific 
portion of telephone number) is collected. Further, the standardized electronic mail addresses 
created by Agraharam are different: they must include the entire telephone number - this is 
Agraharam* s main objective, as it its very purpose is to allow emailing by use of knowledge of one' s 
telephone number - and optionally may include a first name and/or country code (e.g., .us, .uk, xa). 
Family name (surname) is irrelevant; it does not trigger generation of the Agraharam standardized 
electronic mail address, nor is it used in the Agraharam standardized electronic mail address. 
Similarly, no postal address locator code is used for triggering email address generation, nor is it 
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used in the Agraharam email address, save for as part of the overall telephone number used as the 
foundation for the Agraharam email address. 

AccordingtotheUSPTO'snew£j^/wzwa/70rt Guidelines/or Determining Obviousness Under 
35 U.S. C. 103 in View of the Supreme Court Decision in KSR Internationa! Co. v. Teteflex Inc., at 
72 Federal Register 5 7 5 2 6 (currently available at 
http://www.u^to.gov/webyoffices/cx)in/sol/notices/72fr any obviousness rejection must 

clearly identify the differences between the claimed invention and the prior art. The foregoing 
discussion is believed to accurately identify the differences between claim 1 (and 7 and 23) from 
Agraharam. In any subsequent Office Action, for purposes of further Response or appeal, kindly 
indicate whether the Office agrees whether these are the differences between the claimed invention 
and Agraharam. With respect, the current rejections do not correctly identify the differences 
between the claimed invention and Agraharam, and are confusing because they cite extended 
passages of Agraharam which do not seem to apply to the claim limitations in issue. To illustrate, 
looking specifically to the rejections of claim 1 (and 7 and 23) at page 8 of the Office Action, it is 
alleged that Agraharam et al includes: 

instructions operable to create an at least partial entry for the individual in an index 
of individuals in a database, the at least partial entjy being based on the collected name and 
known location data of the individual (usage of database and alias addressing mechanism, 
directory, registry, col. 7 6, lines 6 - 67); 

The cited passages of Agraharam do not in feet appear to disclose this matter. The cited column 6 

lines 6-67 of Agraharam discuss the ability of users of the Agraharam system to look up the email 

addresses of other users: a seeking user first enters his/her own telephone number and PIN number 

to verify that he/she is an authorized user. If the seeking user is an authorized user, the seeking user 

may enter the telephone number of the user he/she seeks (the sought user), and the Agraharam 

system will then return the sought user's email address (so long as the sought user does not have an 

unpublished telephone number and email address). Otherwise, the cited column 6 lines 6-67 contain 

a detailed description of how a PIN number is securely provided to a user. 
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In contrast, claim 1 recites: 

b. instructions creating an at least partial enay for the individual in an index of 
individuals in a database, the at least partial entry being created once the name data 
and the known location data of the individual are collected; 

Claims 7 and 23 contain similar recitations. The limitations recited in clause b of claim 1 basically 

state that a database of individuals is compiled, with at least partial entries being created for each 

individual once name data and location data are collected for the individual. Agraharam, in contrast, 

creates a database for individuals once telephone number and primary email address are known for 

an individual: this is all Agraharam needs to operate in the manner described at the cited column 

6 lines 6-67. Agraharam does not in fact disclose or in any way suggest the recited limitations of 

clause b: why would Agraharam be modified to begin constructing database entries once name and 

location data are collected for an individual, given that Agraharam'* system relies on telephone 

numbers and (primary) email addressed 

As another illustration, at page 8 of the Office Action, it is further alleged that Agraharam 

et ah includes: 

instructions operable to handle a standardized electronic mail address for the 
individual once both name and known location data have been collected (e.g., coL, I, lines 
22- 57) wherein the name data includes at least the family name of the individual and the 
location data includes a region specific portion of a telephone number (e.g., col.. 5, lines 24 
^58) 

Again, the cited passages of Agraharam do not in fact appear to disclose this matter. The cited 
column 1 lines 22-57 of Agraharam simply note that conventional email messages take the form of 
recipient_name@domain_name, and are difficult to use because one cannot send an email to a 
recipient unless the recipient's email address is properly known/remembered. The cited passage 
further notes QiztAgraharam addresses this by linking telephone numbers and email addresses, such 
that users are assigned an "alias" email address - a secondary email address consisting of the user's 
telephone number - which, when emailed, relays the email to the user's primary email address. 
Thus, all an email sender needs to know/remember of the email recipient is his/her telephone 
number. The cited column 5 lines 24-58 of Agraharam then note that when multiple users share the 
same telephone number, the alias email address may be constructed of a telephone number and a 
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name; and further, users will not be able to access the Agraharam system unless they sign up for it, 
and provide their telephone number and primary email address (column 5 lines 49-52, see also 
column 3 lines 35-41). 

In contrast, claim 1 recites: 

c. instructions triggering generation of a standardized electronic mail address for the 
individual once both the name data and the known location data have been collected 
wherein: 

(1) the name data includes at least a family name of the individual, and 

(2) the location data includes one or more of 

(a) a country specific postal address locator code, 

(b) a region specific portion of a telephone number, 

Claims 7 and 23 contain similar recitations. The limitations recited in clause c of claim 1 basically 
state that once at least a family name and either (a) a postal address locator code (e,g. 5 a zip code) 
or (b) a region specific portion of a telephone number (e.g., a telephone area code) is collected, a 
standardized electronic mail address will then be created. Agraharam, again, creates an alias email 
from one's telephone number (and possibly from a portion of one's name, and/or from one's 
country, column 5 lines S-37) once a user enters their telephone number and primary email address 
(colurnn 5 lines 49-52, see also column 3 lines 35-41). Agraharam therefore does not in fact 
disclose the recited limitations of clause c, not would it be obvious to modify Agraharam to meet 
the limitations of clause c: again, all Agraharam needs to create an alias email address is telephone 
number and primary email address (column 5 lines 49-52 7 column 3 lines 35*41). Why would 
Agraharam instead wait to generate an alias email address for an individual only once a family name 
and either (a) a postal address locator code (e.g., a zip code) or (b) a region specific portion of a 
telephone number (e.g., a telephone area code) is collected for an individual? 

The Office Action appears to assert (stpage 9) that the sole difference between the invention 
of claim 1 (and claims 7 and 23, see Office Action page 11) is that Agraharam does not disclose a 
trigger to generate the email address, relying on "Official Notice" to state that such a trigger would 
be obvious. However, a review of the references cited in support of the "Official Notice" appears 
to indicate that the inventions therein either (1) simply already have a database which includes email 
addresses, and they generate an email to a recipient at the email address upon occurrence of some 
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event, or (2) generate an email address in the same manner as Agraharam, in that once they have 
some type of data- like Agraharam' s telephone number - they generate an email address therefrom. 
The Applicant does not dispute that the prior art discloses construction of email addresses 
"triggered" by a certain event; Agraharam itself does so, as it constructs its alias email address once 
a telephone number and primary email address is entered by a registered user (column 5 lines 49-52, 
column 3 lines 35-41). However, as discussed above, the prior cert does not disclose - and it is not 
seen to be obvious - to collect name and location data for inclusion in a database, and then trigger 
generation of a standardized email address for inclusion in the database only when the collected 
data includes a family name and either (a) a postal address locator code (e.g., a sip code) or (b) a 
region specific portion of a telephone number (e.g. t a telephone area code). Further, as discussed 
above, the prior art does not disclose generation of a standardized email address having the same 
content/elements as those claimed. If the Office nevertheless believes Agraharam or another 
reference of record to disclose these features, kindly identify with particularity the location and 
content of the alleged disclosure or suggestion so that the Applicant may better respond. 1 Again, 
with respect, the citation of extended passages of text from prior art is not helpful, as opposed to 
citations which particularly identify the features in question. This is particularly true insofar as many 
of the citations seem inaccurate, in that the text being cited does not in fact disclose what the Office 
Action alleges that it discloses. The issues in this application will be more rapidly resolved if the 
differences between the claimed invention and prior art are clearly and accurately identified for the 
record. 

6«b. Determination of Unobviousness 

As noted in the foregoing Examination Guidelines for Determining Obviousness Under 35 
U.S.C. 103 in View of the Supreme Court Decision in KSR International Co. v. Teleflex Inc., once 
the Graham factual inquiries are resolved - such as the differences between the claimed invention 



1 See 37 CFR §L104(cX2): T, When a reference is complex or shows or describes inventions other than 
that claimed by the applicant, the particular part relied on must he designated as nearly as practicable. The 
pertinence of each reference, if not apparent, must be clearly explained and each rejected claim specified." 
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and the prior art (as discussed in the foregoing Section 6.a of this Response) - Office personnel must 

determine whether the claimed invention would have been obvious to one of ordinary skill in the art 

At page 57528, it is stated that "Office personnel must explain why the difference(s) between the 

prior art and the claimed invention would have been obvious to one of ordinary skill in the art," and 

it is further stated at pages 57528-57529 that: 

The key to supporting any rejection under 35 LLS.C* 103 is the clear articulation of the 
reason(s) why the claimed invention would have been obvious. The Supreme Court in KSR 
noted that the analysis supporting a rejection under 35 U-S.C. 103 should be made explicit. 
The Court quoting/n reKnkn stated that ac [R] ejections on obviousness cannot be sustained 
by mere concluso ry statements; instead, there must be some articulated reason ing with some 
rational underpinning to support the legal conclusion of obviousness. 5 " 

We submit that the claimed invention - which in accordance with §103 must be considered as a 

whole, and at the time the invention was made (i.e. ? without hindsight) — is not obvious to an 

ordinary artisan. As noted above, the claimed invention collects name and location data and creates 

an at least partial entry in the database, and only creates an email address once sufficient name and 

location data are found — once the name data includes a family name (surname), and once the 

location data includes one or more of a country specific postal address locator code (e,g. > a zip code) 

and/or a region specific portion of a telephone number (e.g., an area code). The prior art does not 

create any such "partial entry" database, and one of ordinary skill would not think to construct such 

a database because it would be expected to contain numerous partial entries (which therefore do not 

include standardized email addresses) - which are effectively unusable, since they do not include 

standardized email addresses - rather than "complete" entries (those which include a family name 

and a postal address locator code and/or a region specific telephone code, and which therefore 

include a generated standardized email address). If the objective of the invention is to generate a 

database of standardized email addresses, what is the use of collecting partial entries which include 

no standardized email addresses, and including these in the database? Thus, the prior art does not 

take this approach, and like Agraharam (and some of the other references noted at page 9 of the 

Office Action), it only adds an entry to a database once it has the complete information needed to 

construct an email address (and the database entry then includes the constructed email address). 
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Alternatively, like some of the other references noted at page 9 of the Office Action, email addresses 
are not constructed at all, and rather a database i$ simply collected of email addresses, names, 
addresses, etc., and one can then reference the database entries to contact an individual via any of 
email, phone, mail, etc. 

Claims7and23 have also been amended to specifically recite that the generated standardized 
email address includes at least the family name of the individual. While email addresses often 
include last names (as acknowledged, for example, by Agraharam at column 1 lines 22-23), we 
submit that in the context of the invention as a whole (as required by §103), this feature is also 
unobvious over Agraharam: if one wishes to construct a system whereby an individual can be easily 
reached by email without knowledge of their true/primary email address, use of a telephone number 
(as in Agraharam) is logical. However, inclusion of a family name (surname) is not: if the surname 
is not a common one (and they often are not), they are easily misspelled, which would thwart 
delivery of the email. Thus, note that Agraharam only suggests use of first names in an email 
address (column 5 lines 24-37), and even then only where multiple people having the same family 
name share the same telephone number. When it is considered that Agraharam is intended to 
provide a way for a sender who only knows a recipient's telephone number (and first name) to 
compose an email address for the recipient, why would one incorporate the email address features 
of claims 7 and 23, which would only increase the amount of information that a sender needs to 
know in order to send an email, and which would also increase the risk of error (in case a sender did 
not accurately know family name and one or more of zip code and area code)? 

7. Section 18 of the Office Action: Rejection of Dependent Claims 4 and 10 under 35 USC 
§1 03(a) in view of U.S. Patent S.987.508 to Agraharam et &L 

Agraharam also does not disclose or suggest the invention of dependent claims 4 and 10, 
which recite that the standardized email addresses are automatically created without individuals' 
need to provide name and location data. In contrast, Agraharam requires that a user must register 
with the provider of the service, including providing his/her actual/primary email address and 
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telephone number (see column 3 lines 35-41, column 5 lines 49-52), before an alias email address 
can be generated. 

The Office Action cites column 5 lines 24-58 as allegedly disclosing this feature, but again 
the citation seems overbroad and incorrect 

• Column 5 lines 24-3 7 note that since multiple people may share the same telephone number, 
multiple recipients may register with the same telephone number (and with different primary 
email addresses). In this case, so that emails sent to an alias email address are sent to the 
correct recipient at his/her correct primary email address, a name may be added to the alias 
email addresses (such as 2015558765.steve@emaiLatt.net) so that the alias email is directed 
to the desired individual at his/her correct primary email address. 

• Column 5 lines 38-58 then state exactly the contrary of the claimed matter: this section 
clearly states that a user must register, and provide his/her actual/primar)? email address 
and telephone number, before an alias email address can be generated. See particularly 

1 column 5 lines 49-52. 

Again, if it is believed that Agraharam or another reference of record discloses the features of 
claims 4 and 1 0 7 kindly identify with particularity the location and content of the alleged disclosure 
or suggestion so that the Applicant may better respond. Agraharam is simply not seen to disclose 
the matter the Office Action alleges it discloses. 

JL Section 20 of the Office Action: Rejection of Dependent Claims 6, 12, 16. and 20 under 
35 USC S1036O in view of U.S. Patent 5.987.508 to Agraharam et al 
The Office Action alleges float it would be obvious to attach a unique numeric identifier to 
an Agraharam email. However, this does not make sense. Agraharam seeks to provide a solution 
to unknown email addresses by allowing senders to send emails to alias addresses based on the 
recipients' phone numbers (which the senders do know). If a unique numeric identifier was added 
to such alias addresses, senders would not know ihe numeric identifiers and would not know how 
to compose the alias addresses, and (he invention would not function for its intended purpose. 
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Further consider that since Agraharam* s alias email addresses are based on telephone numbers, all 
alias email addresses will be unique except where multiple recipients share the same telephone 
number — and Agraharam addresses this by appending the first names of the recipients, rather than 
adding any numeric code (see column 5 lines 24-37). A sender would naturally know the first name 
of the recipient that he/she seeks to email, and thus appending a first name to the Agraharam email 
is not problematic. In contrast, unlike a telephone number or first name for a recipient, a sender 
would not know any unique numeric identifier assigned to a recipient, and would therefore not be 
able to readily email a recipient as Agraharam intends. Thus, we submit that claims 6, 12 s 16 s and 
20 are novel and unobvious. If it is asserted otherwise, please explain: if a unique numeric identifier 
was attached to Agraharam' $ telephone number-based email addresses, how would a sender who 
seeks to email the recipient, and who knows no more than the recipient's telephone number (and/or 
the recipient's name), be able to guess the numeric identifier and email the recipient? 

Please note that this question and others were posed in the last Response, but the Office 
Action does not offer a reply. Kindly provide a reply in any subsequent Office Action. See MPEP 
707,07(f), Answer All Material Traversed ("Where the applicant traverses any rejection, the 
examiner should, if he or she repeats the rejection, take note of the applicant's argument and answer 
the substance of it"); also see Examiner Notes for PTO form paragraphs 7,37 and 7.38 (as 
reproduced in MPEP 707.07), which require that all relevant arguments by the Applicant be 
addressed. 

« 

9. Remaining Claims / Rejections 

Tbe remaining claims are submitted to be allowable for at least the same reasons as claims 
1, 7, and 23, from which all remaining claims depend. 
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10- In Closing 

If any questions regarding the application arise, please contact the undersigned attorney. 
Telephone calls related to this application are welcomed and encouraged. The Commissioner is 
authorized to charge any fees or credit any overpayments relating to this application to deposit 
account number 18-2055. 



For the Applicant, 




Craig A.^fieschko, Reg. No. 39,668 
DEWITT ROSS & STEVENS S.C. 
Excelsior Financial Centre 
8000 Excelsior Drive, Suite 401 
Madison, Wisconsin 53717-1914 
Telephone: (608) 828-0722 
Facsimile: (608) 831-2106 
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